After throrough investigation and lots of time spent, I figured out why
the `fs` patch didn't resolve paths within the `.runfiles` directory.

The .runfiles directory of e.g. a js_binary (with bazel run) does have symlinks
for e.g. node_modules/verdaccio point to the execroot directly via an absolute symlink.

This is weird because in other projects there are relative symlinks to
the store (this is important for the sandbox escaping FS patches)), as
otherwise the dereferencing is blocked/prevented and we'd never resolve
into a store directory— preventing transitive deps from being properly
resolved.

After figuring this out, I've tracked down the Bazel issue and found a
fix: bazelbuild/bazel@51d7a3c

In addition, there seems a related `rules_js` issue that has the same
investigation results:
aspect-build/rules_js#1877

We should try this out, but keep an eye on Firefox and Chromium. Those
browser artifacts might contain files with spaces. This is incompatible
with the Bazel version we are using, so the inprocess runfile creation
was a workaround for this— If we remove that flag, we might cause issues
for Mac users.

We have a few options I think:

1. drop the flag, and hope it doesn't break any runfile generation for
  browsers. I suspect it won't work...— alternatively try renaming
  browser files.

2. keep the flag for now, and temporarily keep the disabled FS patches
  (needs to be manually specified by users)

3. do solution (2) but once migration allows it, update to Bazel 7— so
  that the bug with inprocess resolution is nicely fixed.

I think (3) is a good plan moving forward and we don't need any runfile
tricks. In Bazel 8, the runfiles with space issue is also resolved—
allowing us to drop the inprocess runfile creation as well (if we want).